1. Field of the Invention
The invention relates to the initial development and later adaption of applications and in particular to information systems which include a database and one or more clients or user-interfaces. The invention goes beyond the simple storage of content data in the database to the storage of system data, application data and rule data required to develop and run an information system. On connecting to the database a client or user-interface program loads the system data, application data and rule data to generate an information system.
2. Relevant Background
Information systems are well-known. Examples include accounting, stock control and contact management systems. At a simple level, each of these systems comprise a database and one or more clients or user-interfaces. At an intermediate level of detail, they comprise tables, content data, data sets, forms and rules. At a more detailed level, an information system is composed of tables, fields, data types, indexes, data sets, entities, columns, joins, filters, data sources, menus, menu widgets, toolbars, tool widgets, forms, form widgets, events, functions, blocks, iterations, conditions, tests and statements.
While a stock control system will clearly have a different set of application tables, fields, data sets, forms, rules and content data to a contact management system both information systems are made up of substantially the same features like tables, content data, data sets, forms and rules. It is in the number and behaviour of these features that information systems differ.
The behaviour of each of these features has to operate in harmony with the behaviour of the other features for the system to work correctly. Assume an information system has a number of tables, fields and rules. It is not uncommon, either during the initial development or later adaptation, for the data structure of an information system to be changed. This means that tables and fields might need to be added, renamed or removed. However, the action of changing the data structure means that anything dependent on that data structure will also need to be updated. For example, any relationship rules between the tables may have to be updated and any validation rules which reference a changed field will have to be updated. As updates are made so the developer has to ensure that those changes do not affect features further up the stack. Clearly, the lower in the stack that a change is made, where the chain of dependencies is longer, the more checks and updates need to be performed and the more time-consuming and error-prone changes become.
What makes the initial development and later adaptation of information systems using the traditional architecture time-consuming and error-prone is that the traditional architecture does not make it easy to identify dependencies or to conclusively verify the correctness of an application.
The way in which features are defined in the traditional architecture do not make it easy for dependencies to be identified. Often in the traditional architecture the definitions of tables and fields are embedded in the database API, Application Programming Interface; rules are defined in a proprietary procedural SQL, Structured Query Language, in the database or in C++ or Basic in the client or user-interface; data sets are defined as SQL strings and user-interface elements are defined in C++ or Basic. It therefore requires the developer to locate and search through the code to identify and update dependencies and to verify that references point to actual objects and that those referenced objects are computationally compatible.
Information systems differ architecturally in where they incorporate different features; the database, the client or user-interface or any combination of these. Content data is always stored in the database and forms are always a feature of the user-interface. But rules and data sets can be defined in the database, the client or user-interface or a combination of any of these and even sometimes reproduced in the database, the client or user-interface. The effect of this distribution of features is that developers can only really demonstrate the correctness of a system by testing every possible combination of behavior at run-time.
Given that information systems are so difficult to build, update and verify it is little wonder that users buy off-the-shelf packages and adapt their processes to the package rather than adapting the package to their processes. It is also the reason why customized systems are so time-consuming, expensive and error-prone and why so much development overshoots schedules and budgets and why so many projects fail altogether.
What is needed is an architecture which allows information systems to be developed and adapted quickly and where the application can be assured of correctness irrespective of whatever changes it is subjected to.